NoSQL and transactions: 


getting the numbers out 
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Goals of the test 


ACID properties 

scalability 

price/performance: is it better than RDBMS? 
http://github.com/picodata/stro 


STRO,PPY 


www.stroppy.io 


Test subjects 


PostgreSQL 
FoundationDB 
CockroachDB 
MongoDB 
YDB? 


Applying the banking test one more time 


e load account data 


e run money transfers 
o nemesis, 
o transaction distribution: Uniform, Zipfian 


e check total balance, check no transaction is lost 


PostgreSQL illustration: accounts and transfers 


CREATE TABLE IF NOT EXISTS account ( 
bic TEXT, -- bank identifier code 
ban TEXT, -- bank account number within the bank 
balance DECIMAL, -- account balance 
PRIMARY KEY (bic, ban) 
/ 
CREATE TABLE IF דסא‎ EXISTS checksum ) 
name TEXT PRIMARY KEY, 
amount DECIMAL 


) 


PostgreSQL illustration - accounts and transfers 


BEGIN 
UPDATE account SET balance = balance - $1 
WHERE bic = $2 and ban = $3 
UPDATE account SET balance = balance + $1 
WHERE bic = $2 and ban 3 
COMMIT 


Transfer account number distribution 
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Hardware 


Oracle Cloud: Yandex Cloud: 
1Gb of disk/network Intel Xeon® Processor 
bandwidth per core Е5-2660 v4, 4 Gb 


RAM, Network-SSD 15 
Gb 
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PostgreSQL results 


VCPU/ RAM/ HDD/ Clients 
node node, GB Node, GB 

9 30 100 128 
10 160 1000 256 


PostgreSQL 13.2. Zalando PostgreSQL operator 


PostgreSQL limits 


CPU Basic 1/O Usage Read / Write 


current 
fully read bytes 0 /s 21 /s 0 B/s 
1310 13 3:30 1340 13:50 14:00 0 3 : 0 00 . cessfully written bytes B 2 2 99.248 kB/s 


Busy IRQs Busy Other Idle Disk IOps 


Network Traffic Basic 


es KAAN 
20 Mb/s WWW ٧ 


dockerü سه‎ recy ens3 с ecv = recvlo aldns есу veth05385f94 есу veth4cb8f7d2 
ethccdedda8 nid 5 ns3 سه‎ flannel.1 
rans nodelocaldr 0 — trai h 63455911 == trans veth789393b9 


trans veth87186545 سه‎ t ccdedda8 5 completed 


FoundationDB architecture 


Control Plane 


Coordinators Cluster Data 


Rate 
1 * Controller Distributor keeper 


Data Plane 
( Transaction System (TS) À 
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! Client Transaction | ; "₪ 
| - 32 
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Transaction RPCs ----* 


Async. data copy ----* 


FoundationDB results 


Nodes VCPU/ RAM/ HDD/ Clients Account Transfer TPS 


node node, GB Node, GB S, S, 
millions millions 
3 1 8 100 16 10 100 2709 
3 2 8 100 16 10 100 2189 
5 1 8 100 52 10 100 7631 
5 1 16 100 512 100 100 0/82 


20 1 16 100 512 100 100 10854 


FoundationDB results 
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FoundationDB vs PostgreSQL 


TPS per core 


E FoB ₪ Pc 


FoundationDB bottlenecks 


CPU Basic 1/0 Usage Read / Write 


max 
sfully read bytes 0 99 MB/s 


: sfully written bytes 195.880 kB/s 29.934 MB/s 
Busy IRQs => Busy Other سه‎ Idle 


Disk lOps Network Traffic Basic 


00 13:10 0 0 0 1400 0 4:40 0 от 2:5 3:10 3 3:30 13:40 13:50 ] 
veth05385194 
0 ans docker 
odelocaldns == trans veth05385f9. а! = trans veth63d55911 


s vethccdedda8 


MongoDB architecture 


| Application 
| Driver | 


MongoDB - vertical scalability 


VCPU/ RAM/ HDD/ Clients Accounts, Transfers, TPS 

node node, GB Node, GB millions millions 

2 8 100 16 10 10 720 

4 8 100 128 10 10 1843 
6 16 100 128 100 100 2/61 


12 40 1000 128 1000 100 3272 


MongoDB - horrorzontal scalability 


VCPU/ Shards RAM/ HDD/ Clients Account Transfer TPS 


node node, Node, S, $, 
СВ СВ millions millions 
2 8 100 32 10 10 427 
8 8 100 128 100 10 1171 


8 8 100 128 1000 100 947 


FoundationDB vs PostgreSQL vs MongoDB 


TPS per core 


Ш гов В PG В Mongo 
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CockroachDB results 


VCPU/ Shards RAM/ HDD/ 


node node, Node, 
GB GB 

2 3 8 100 

1 5 16 100 

1 20 16 100 


YDB results 


VCPU/ Shards RAM/ HDD/ Clients Account Transfer TPS 


node node, Node, S, $, 
СВ СВ millions millions 
16 3 24 100 4000 1 10 15367 


Latency min/99%/max/med: 0.390s/1.129s/3.936s/0.998s 


YDB - load charts - CPU 
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YDB - load charts - disk 
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YDB - load charts - disk 
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YDB - load charts - network 
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Chaos mesh tests 


PostgreSQL - n 
FoundationDB - 
CockroachDB - ? 


MongoDB - [4 


Summary 


Scaling transactional workloads horizontally is hard 
FoundationDB has been designed from scratch to support it 
MongoDB is performing the worst 

CockroachDB loses to PostgreSQL on the same hardware 
the Go tool and the results are public at stroppy.io 
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Yandex 
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